<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>PowerVB July 20 Update</title>
</head>

<body>

<p><b><font face="Verdana" size="3"><a name="The Top">Advanced Visual Basic 6: Power Techniques for Everyday Programs Readme</a></font></b></a>&nbsp;</font></b></p>
This release of the tools is a much more stable version of what you got on the CD. The CD version of EditTLB.dll has some major problems with actually saving the work, most of which
are fixed with this version. You may still have occasional problems with saving an edited library because VB doesn't like to let go of the typelib. This release also contains the PostBuild.dll add-in discussed in the book. This drop does not contain the promised EditCompat add-in, but I will discuss how to attain many of the EditCompat capabilities with this release.

<br><br>
<b>Contents</b><br>
<br>
There are many things to say about the provided type library editors because there are so many things you can do that are difficult with or impossible with MIDL/mktyplib, these are only a few highlights.<br>
</p>
<ul>
  <li><a href="#Upgrade Installation">Upgrade Installation</a></li>
  <li><a href="#Known Core Issues">Known issues for the core type library editor</a></li>
  <li><a href="#Post-Build Issues">Post-Build Issues</a></li>
  <li><a href="#Post-Build Help Modification">Post-Build Help Modification</a></li>
  <li><a href="#Binary-Compatibility Edits">Editing Binary-Compatibility Files</a></li>
  <li><a href="#void Property Procedures">void Property Procedures</a></li>
<br>
</ul>
<p><b><a name="Upgrade Installation">
Upgrade Installation<br>
</a></b><br>
Upgrading the CD software to the current drop is trivial. Simply expand the Updates720.zip file in the PowerVB directory (C:\Program Files\PowerVB by default) and run Register720.bat to register the new files (TLBEditor.ocx needs re-registering, and PostBuild.dll is new).
<br><br>
<a href="#The Top">Return to top</a></p>
<p><b><a name="Known Core Issues">
Known issues for the core type library editor</b><br><br>
All of the add-ins share a core type-library editing engine, contained in TLBEditor.ocx, which is responsible for accepting valid edits, and recording, serializing, and playing back those edits as well. The editor is designed to run off context menus, which will remain essentially the same wherever you are. You can edit very quickly if you use the context menu key on an extended keyboard, and F2 to start label edits in the treeview. There are a handful of features that have not been completed as of this drop:<br><br>
1) There are no provisions for CustomData editing. This will eventually be available on the context menu for each item (CustomData is finer grained than help editing, which is per member, so it would require one tab per invoke kind, which is too much for the main UI).<br><br>
2) Copy/Paste of members is supported, but does not appear on the context menus. Duplication of entire types is supported for external types, but not internal. Parameter Copy/Paste is also not implemented.<br><br>
3) You can put a uidefault flag on multiple elements. oleaut doesn't check this, but I will do so in the future to automically turn off old values.<br><br>
4) You may get an obscure error message that says 'RedirectType replaced a type with Nothing, but the type is being used elsewhere in the library.' The bottom line is that the type is in use and you can't delete it, but it would be nicer if I told you what element was using it.<br><br>
5) The constant editing will get a small shadow window that will show you resolved escape sequences, hex constant values, etc. You can type in in hex with an &H prefix, but you can't see the text back in hex with the current implementaton.<br><br>
6) Some of the most powerful editing features in the editor allow you to internalize and/or redirect external types. Unfortunately, the UI for these is obscure. The redirection commands for internal types are on the normal context menus, but external types don't have nodes in the tree, so they are less accessible. To redirect or internalize an external type, simply right click on the Type display to get the context menu. There is currently no keyboard access for this feature. You can distinguish external types by the <i>LibName.</i> prefix before the actual type.<br
</blockquote>
<a href="#The Top">Return to top</a></p>
</a></b><br>
<p><b><a name="Post-Build Issues">
Post-Build Issues</b><br><br>
There are several things you can do during post-build editing that can break your finished product. Some of these I should warn you about, and some I should support. One of the most sensitive operations with post-build editing is updating the exe/dll/ocx file itself to make it properly load records with non-GUID_NULL guis that have been internalized into the typelib. Currently, internalized record guids are tracked properly, but records that are redirected are not tracked properly. The guid requirements are discussed in chapter 15.<br>
You should not try to edit the GUID, name, or base of a VB-generated type. I'll probably block this in later releases. GUID changes should be made in the compatibility file.<br>
As you step through the post-build playback mechanism, you may notice that you can't see the target of a change before the change occurs, and you can't delete edits before the current statement. To backout a line, you need to run the Restart command, and use a breakpoint or the Run To Cursor command to stop on the command in question.<br><br>
<a href="#The Top">Return to top</a></p>
</a></b><br>
<p><b><a name="Post-Build Help Modification">
Post-Build Help Modification</b><br><br>
The Post-Build editor lets you specify a Help Modifier class, which you program yourself. Changes made via this class do not show up in the editor as they are made during the Save phase. This lets you use a database of you own choosing to put help information in your projects, and lets you use a satellite Dll for localized help information if you like. The interface use TLI (TypeLib Information) objects. You can get a help file for these objects from <a href="http://msdn.microsoft.com/vbasic/downloads/addon.asp">http://msdn.microsoft.com/vbasic/downloads/addon.asp</a> . A sample implementation is shown below. Note that the only unusual thing here is that you will get two requests for Type help because some help information must be specified before a type is added, and some after. Generally, you will use the library's HelpStringDll settings (alternate HelpFile settings don't work on types), so you only need to pay attention to the hfNonFileFields FieldMask values. The IModifyHelpData interface is defined in TLBEditor.ocx, which you'll have to add with Browse/References to use it without the controls.<br><br>
<code>
Implements IModifyHelpData<br><br>

Private Sub IModifyHelpData_SetLibraryHelpData(ByVal Library As TLI.TypeLibInfo, HelpData As TLBEditor.HelpData)<br>
&nbsp;&nbsp;&nbsp;&nbsp;HelpData.HelpString = "Help for library " & Library.Name<br>
End Sub<br><br>

Private Sub IModifyHelpData_SetMemberHelpData(ByVal TypeInfo As TLI.TypeInfo, ByVal Member As TLI.MemberInfo, HelpData As TLBEditor.HelpData)<br>
&nbsp;&nbsp;&nbsp;&nbsp;HelpData.HelpString = "Help for member " & TypeInfo.Name & "." & Member.Name<br>
&nbsp;&nbsp;&nbsp;&nbsp;HelpData.HelpContext = Member.MemberId<br>
End Sub<br><br>

Private Sub IModifyHelpData_SetTypeHelpData(ByVal TypeInfo As TLI.TypeInfo, ByVal FieldsMask As TLBEditor.HelpFields, HelpData As TLBEditor.HelpData)<br>
&nbsp;&nbsp;&nbsp;&nbsp;If FieldsMask And hfNonFileFields Then<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HelpData.HelpString = "Help for type " & TypeInfo.Name<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HelpData.HelpContext = TypeInfo.TypeInfoNumber<br>
&nbsp;&nbsp;&nbsp;&nbsp;End If<br>
End Sub<br><br>
</code>
<a href="#The Top">Return to top</a></p>
</a></b><br>

<p><b><a name="Binary-Compatibility Edits">
Editing Binary-Compatibility Files</b><br><br>
Until I get the EditCompat add-in completed to give you integrated compatibility editing, you can still use the type library editing pieces provided to make changes to you compatibility files. However, there is no filtering in place to control what you do. Note that editing the typelib is easy with EditTLB.Exe, but you should avoid much of what is available. After you've made your edit and saved to another file, use MSVC in resource editing mode to import the .tlb file and replace your old one (be sure to match the id number and locale settings).<br><br>
You can change GUIDs, delete old alias types, change member names, etc, but you shouldn't try to add new types because VB likes its own ordering, and you won't get it right. If you change a type name, then you also need to change the name of the corresponding interface-identifier resource. VB will pick up a new guid from the typelib the next time you build, so you don't have to worry about editing the binary guid values.<br><br>
One of the strangest things VB does with typelibs is generate non-standard MemberID values. VB interfaces are IDispatch-derived, so MemberIDs on custom members should start at &H60020000, but VB starts them at &60030000 and doesn't like the *2* numbers. If you add a member, be sure to change the MemberID to match the other ones VB spits. You can use the 'Reset MemberIDs' command to generate a fresh batch of &H6002* numbers, but you'll have to change all the 2's back to 3's or VB will refuse to compile against your compatibility file. You should also keep your Type Constraints set to VB Implementable for compatibility editing.<br><br>
You can also use the Binary Compatibility Editing tool on the Microsoft site to extend your interfaces, enums, etc without keeping a chain of obsolete guids. See <a href="http://msdn.microsoft.com/vbasic/downloads/addon.asp">http://msdn.microsoft.com/vbasic/downloads/controls.asp</a><br><br>
<a href="#The Top">Return to top</a></p>
</a></b><br>

<p><b><a name="void Property Procedures">
void Property Procedures</b><br><br>
The books states that you cannot return void from a Property Get procedure. In truth, this is a MIDL limitation, not an oleaut/typelib limitation, and you can set these up nicely with the type lib editores for use with lightweight objects (VB won't let you Implement anythng that doesn't return an HRESULT). The advantage of the void property get definitions is that the retval parameter is expected as the return value, not an [out,retval], for values which are returned on the stack (<8 bytes). For example, a void property get returning a long has a signature in VB of 'Function MyFunc() As Long' instead of 'Function MyFunc(ByVal retVal As Long) As Long'. Larger types (Variants, etc) use the retVal parameter. This makes lightweight objects cleaner because you can use both Property definitions and void return types. Remember that the HRESULT is just baggage for internal lightweights because VB translates it back into an exception anyway after catching it, so you might as well throw directly.
<br><br>
<a href="#The Top">Return to top</a></p>
</a></b><br>


</font></p>

</body>

</html>
